介紹 Kubernetes 的起源，通常會說 Kubernetes 是從 Google 內部系統 Borg 開源出來，但這樣的介紹方式，容易讓人誤解成，Kubernetes 就是開源版本的 Borg，但是實際上，Kubernetes 跟 Borg 有許多差異，所以這邊特別花上一個章節介紹。

Borg 的單體式架構

Borg 採用單體式架構，所有控制平面功能都由 Borg Master 管理。 Borg Master 負責資源管理、任務排程、狀態維護等所有控制平面的任務，包含 UI、水平及垂直擴展、CronJob、工作流程的管理，以及資料歸檔。 這種單體式設計 just work，但在面對需求的變化會缺乏靈活。

Omega 的組件化與分散式架構

Omega 的設計目標是改善 Borg 系統。 它沿用了許多在 Borg 中被證明成功的概念，但從頭開始構建，以擁有更一致、更有原則的架構。

組件化架構 是 Omega 的核心突破。Borg 原本由單一的 Borg Master 承擔所有控制功能，而在 Omega 中，這些功能被拆解成多個獨立的組件，這些組件之間透過定義明確的介面進行溝通。這帶來了幾個顯著的優勢：

• 靈活性：組件可以獨立開發、部署和更新，不會因其他組件的變動受到影響。
• 擴展性：根據需求擴展特定組件，而不必擴展整個系統，這大大提高了整體系統的效率。

此外，Omega 採用了基於 Paxos 演算法的分散式架構來儲存叢集狀態，而非像 Borg 將所有狀態儲存在單一節點中。這使 Omega 在可用性和容錯能力上有了顯著的提升，即便共享存儲故障，系統仍能保持運行。

Omega 的這些分散式設計後來被合併回 Borg，這也是為什麼人們常說 Kubernetes 源自 Borg，但事實上，Kubernetes 的許多設計靈感來自 Omega 的組件化與分散式架構。

Kubernetes 是 Google 開發的第三個容器管理系統，Kubernetes 的模組化設計理念深受 Borg 和 Omega 的影響，從它們的設計問題中吸取了經驗。

API Server 為單一入口： Kubernetes 將 API 伺服器作為系統的單一入口點，所有其他組件，例如 Controller，都只能通過 API Server 來訪問和操作 Kubernetes 的狀態對象。這樣的中心化管理保證了一致性，但是又允許客戶端透過 API Server 維護自己的狀態在 etcd 中，同時達到靈活以及一致性。

基於標籤的物件管理： Borg 用 Job 將具有相同功能的 Task 分組，並用 Vector 做管理，每個 Task 在 Vector 中都有固定的 Index。因此，當一個 Task 重新啟動時，Vector 的同一個位置必須同時指向新啟動的副本和舊的副本以便用於除錯，這就導致了 Task 向量中的混亂，且難以管理。

Kubernetes 使用 label 來組織和管理其排程單元 (Pod)。標籤是使用者可以附加到系統中任何物件上的任意key/value。透過 label selector，可以選擇具有特定 label 的物件集合，並對其進行操作。

Extenable API： Kubernetes 的 API 被設計為可擴展的，允許使用者添加自己的 API 來擴展功能。這種擴展性使得 Kubernetes 可以適應不同的應用場景和需求。

Borg, Omega, Kubernetes 這三個系統從單體式架構、分散式架構到微服務架構，這樣的發展架構符合最近的軟體開發趨勢，所以當做 case study 跟大家分享。